Глава 14: Извлечение знаний (RAG)
LLM демонстрируют значительные возможности в генерации человекоподобного текста. Однако их база знаний обычно ограничена данными, на которых они были обучены, что ограничивает их доступ к информации в реальном времени, специфическим корпоративным данным или высокоспециализированным деталям. Извлечение знаний (RAG, или Retrieval Augmented Generation) решает это ограничение. RAG позволяет LLM получать доступ к внешней, актуальной и контекстно-специфической информации и интегрировать её, тем самым повышая точность, релевантность и фактическую основу их выходных данных.
Для AI-агентов это крайне важно, поскольку позволяет им основывать свои действия и ответы на данных реального времени, поддающихся проверке, выходящих за рамки их статического обучения. Эта возможность позволяет им точно выполнять сложные задачи, такие как доступ к последним корпоративным политикам для ответа на конкретный вопрос или проверка текущих запасов перед размещением заказа. Интегрируя внешние знания, RAG превращает агентов из простых собеседников в эффективные, управляемые данными инструменты, способные выполнять значимую работу.
Обзор паттерна извлечения знаний (RAG)
Паттерн извлечения знаний (RAG) значительно расширяет возможности LLM, предоставляя им доступ к внешним базам знаний перед генерацией ответа. Вместо того чтобы полагаться исключительно на свои внутренние, предварительно обученные знания, RAG позволяет LLM "искать" информацию, подобно тому, как человек может обратиться к книге или поискать в интернете. Этот процесс дает LLM возможность предоставлять более точные, актуальные и поддающиеся проверке ответы.
Когда пользователь задает вопрос или дает prompt AI-системе, использующей RAG, запрос не отправляется напрямую к LLM. Вместо этого система сначала просматривает обширную внешнюю базу знаний — высокоорганизованную библиотеку документов, баз данных или веб-страниц — в поисках релевантной информации. Этот поиск не является простым сопоставлением ключевых слов; это "семантический поиск", который понимает намерение пользователя и смысл, стоящий за его словами. Этот первоначальный поиск извлекает наиболее подходящие фрагменты или "куски" информации. Эти извлеченные части затем "дополняют" или добавляют к исходному prompt, создавая более богатый, более информированный запрос. Наконец, этот расширенный prompt отправляется к LLM. С этим дополнительным контекстом LLM может генерировать ответ, который не только беглый и естественный, но и фактически обоснован извлеченными данными.
Фреймворк RAG предоставляет несколько значительных преимуществ. Он позволяет LLM получать доступ к актуальной информации, тем самым преодолевая ограничения их статических данных обучения. Этот подход также снижает риск "галлюцинаций" — генерации ложной информации — путем обоснования ответов поддающимися проверке данными. Более того, LLM могут использовать специализированные знания, найденные во внутренних корпоративных документах или wiki. Жизненно важным преимуществом этого процесса является способность предоставлять "цитаты", которые указывают на точный источник информации, тем самым повышая надежность и проверяемость ответов AI.
Для полного понимания того, как функционирует RAG, важно понимать несколько основных концепций (см. Рис.1):
Embeddings: В контексте LLM, embeddings — это численные представления текста, такого как слова, фразы или целые документы. Эти представления имеют форму вектора, который является списком чисел. Ключевая идея заключается в том, чтобы зафиксировать семантическое значение и взаимосвязи между различными фрагментами текста в математическом пространстве. Слова или фразы с похожими значениями будут иметь embeddings, которые находятся ближе друг к другу в этом векторном пространстве. Например, представьте простой 2D-график. Слово "кот" может быть представлено координатами (2, 3), в то время как "котенок" будет очень близко на (2.1, 3.1). В отличие от этого, слово "автомобиль" будет иметь отдаленную координату типа (8, 1), отражающую его другое значение. В реальности эти embeddings находятся в гораздо более высокомерном пространстве с сотнями или даже тысячами измерений, что позволяет очень нюансированное понимание языка.
Текстовое сходство: Текстовое сходство относится к мере того, насколько похожи два фрагмента текста. Это может быть на поверхностном уровне, рассматривая пересечение слов (лексическое сходство), или на более глубоком, основанном на смысле уровне. В контексте RAG текстовое сходство имеет решающее значение для поиска наиболее релевантной информации в базе знаний, соответствующей запросу пользователя. Например, рассмотрим предложения: "Какая столица Франции?" и "Какой город является столицей Франции?". Хотя формулировка отличается, они задают один и тот же вопрос. Хорошая модель текстового сходства распознала бы это и присвоила бы высокий балл сходства этим двум предложениям, даже если они разделяют только несколько слов. Это часто вычисляется с использованием embeddings текстов.
Семантическое сходство и расстояние: Семантическое сходство — это более продвинутая форма текстового сходства, которая фокусируется исключительно на значении и контексте текста, а не только на используемых словах. Оно направлено на понимание того, передают ли два фрагмента текста одну и ту же концепцию или идею. Семантическое расстояние является обратным; высокое семантическое сходство подразумевает низкое семантическое расстояние, и наоборот. В RAG семантический поиск полагается на поиск документов с наименьшим семантическим расстоянием до запроса пользователя. Например, фразы "пушистый кошачий компаньон" и "домашняя кошка" не имеют общих слов, кроме артикля. Однако модель, понимающая семантическое сходство, распознала бы, что они относятся к одному и тому же, и считала бы их очень похожими. Это происходит потому, что их embeddings были бы очень близки в векторном пространстве, указывая на небольшое семантическое расстояние. Это "умный поиск", который позволяет RAG находить релевантную информацию, даже когда формулировка пользователя не точно соответствует тексту в базе знаний.
Рис.1: Основные концепции RAG: Разбиение на куски, Embeddings и векторная база данных
Разбиение документов на куски: Разбиение на куски — это процесс разделения больших документов на более мелкие, более управляемые части или "куски". Для эффективной работы RAG-системы она не может подавать целые большие документы в LLM. Вместо этого она обрабатывает эти более мелкие куски. Способ разбиения документов на куски важен для сохранения контекста и смысла информации. Например, вместо того чтобы рассматривать 50-страничное руководство пользователя как единый блок текста, стратегия разбиения может разделить его на разделы, абзацы или даже предложения. Например, раздел "Устранение неполадок" будет отдельным куском от "Руководства по установке". Когда пользователь задает вопрос о конкретной проблеме, RAG-система может затем извлечь наиболее релевантный кусок по устранению неполадок, а не весь руководство. Это делает процесс извлечения быстрее, а информацию, предоставляемую LLM, более сфокусированной и релевантной непосредственной потребности пользователя. После разбиения документов на куски RAG-система должна использовать технику извлечения для поиска наиболее релевантных частей для данного запроса. Основным методом является векторный поиск, который использует embeddings и семантическое расстояние для поиска кусков, концептуально похожих на вопрос пользователя. Более старая, но все еще ценная техника — это BM25, алгоритм на основе ключевых слов, который ранжирует куски на основе частоты терминов без понимания семантического значения. Чтобы получить лучшее из обоих миров, часто используются гибридные подходы поиска, сочетающие точность ключевых слов BM25 с контекстуальным пониманием семантического поиска. Такое слияние позволяет более надежное и точное извлечение, захватывая как буквальные совпадения, так и концептуальную релевантность.
Векторные базы данных: Векторная база данных — это специализированный тип базы данных, предназначенный для эффективного хранения и запроса embeddings. После того как документы разбиты на куски и преобразованы в embeddings, эти высокомерные векторы хранятся в векторной базе данных. Традиционные техники извлечения, такие как поиск на основе ключевых слов, отлично находят документы, содержащие точные слова из запроса, но им не хватает глубокого понимания языка. Они не распознали бы, что "пушистый кошачий компаньон" означает "кот". Здесь векторные базы данных превосходят. Они построены специально для семантического поиска. Храня текст как численные векторы, они могут находить результаты на основе концептуального значения, а не только пересечения ключевых слов. Когда запрос пользователя также преобразуется в вектор, база данных использует высокооптимизированные алгоритмы (такие как HNSW - Hierarchical Navigable Small World) для быстрого поиска среди миллионов векторов и поиска тех, которые "ближайшие" по значению. Этот подход намного превосходит RAG, поскольку он обнаруживает релевантный контекст, даже если формулировка пользователя полностью отличается от исходных документов. По сути, в то время как другие техники ищут слова, векторные базы данных ищут значение. Эта технология реализована в различных формах, от управляемых баз данных, таких как Pinecone и Weaviate, до решений с открытым исходным кодом, таких как Chroma DB, Milvus и Qdrant. Даже существующие базы данных могут быть дополнены возможностями векторного поиска, как видно в Redis, Elasticsearch и Postgres (используя расширение pgvector). Основные механизмы извлечения часто основаны на библиотеках, таких как FAISS от Meta AI или ScaNN от Google Research, которые являются основополагающими для эффективности этих систем.
Проблемы RAG: Несмотря на свою мощь, паттерн RAG не лишен проблем. Основная проблема возникает, когда информация, необходимая для ответа на запрос, не ограничена одним куском, а распределена по нескольким частям документа или даже нескольким документам. В таких случаях извлекатель может не суметь собрать весь необходимый контекст, что приводит к неполному или неточному ответу. Эффективность системы также сильно зависит от качества процесса разбиения на куски и извлечения; если извлекаются нерелевантные куски, это может внести шум и запутать LLM. Кроме того, эффективный синтез информации из потенциально противоречивых источников остается значительным препятствием для этих систем. Помимо этого, еще одной проблемой является то, что RAG требует предварительной обработки и хранения всей базы знаний в специализированных базах данных, таких как векторные или графовые базы данных, что является значительным предприятием. Следовательно, эти знания требуют периодической сверки для поддержания актуальности, что является критической задачей при работе с развивающимися источниками, такими как корпоративные wiki. Весь этот процесс может иметь заметное влияние на производительность, увеличивая задержку, операционные расходы и количество токенов, используемых в финальном prompt.
Подводя итог, паттерн Retrieval-Augmented Generation (RAG) представляет значительный скачок вперед в повышении знаний и надежности AI. Путем беспрепятственной интеграции этапа извлечения внешних знаний в процесс генерации, RAG решает некоторые основные ограничения автономных LLM. Основополагающие концепции embeddings и семантического сходства в сочетании с техниками извлечения, такими как поиск по ключевым словам и гибридный поиск, позволяют системе интеллектуально находить релевантную информацию, которая становится управляемой через стратегическое разбиение на куски. Весь этот процесс извлечения обеспечивается специализированными векторными базами данных, предназначенными для хранения и эффективного запроса миллионов embeddings в масштабе. Хотя проблемы в извлечении фрагментированной или противоречивой информации сохраняются, RAG дает LLM возможность производить ответы, которые не только контекстуально подходящие, но и закрепленные в поддающихся проверке фактах, способствуя большему доверию и полезности в AI.
Graph RAG: GraphRAG — это продвинутая форма Retrieval-Augmented Generation, которая использует граф знаний вместо простой векторной базы данных для извлечения информации. Она отвечает на сложные запросы, навигируя по явным взаимосвязям (рёбрам) между сущностями данных (узлами) в этой структурированной базе знаний. Ключевым преимуществом является её способность синтезировать ответы из информации, фрагментированной по множественным документам, что является частой неудачей традиционного RAG. Понимая эти связи, GraphRAG предоставляет более контекстуально точные и нюансированные ответы.
Случаи использования включают сложный финансовый анализ, связывание компаний с рыночными событиями, и научные исследования для обнаружения взаимосвязей между генами и заболеваниями. Основным недостатком, однако, является значительная сложность, стоимость и экспертиза, требуемые для построения и поддержания высококачественного графа знаний. Эта установка также менее гибкая и может вводить более высокую задержку по сравнению с более простыми системами векторного поиска. Эффективность системы полностью зависит от качества и полноты базовой графовой структуры. Следовательно, GraphRAG предлагает превосходное контекстуальное рассуждение для сложных вопросов, но за гораздо более высокую стоимость реализации и поддержания. Подводя итог, она превосходит там, где глубокие, взаимосвязанные инсайты более критичны, чем скорость и простота стандартного RAG.
Agentic RAG: Эволюция этого паттерна, известная как Agentic RAG (см. Рис.2), вводит слой рассуждения и принятия решений для значительного повышения надёжности извлечения информации. Вместо простого извлечения и дополнения, "агент" — специализированный AI-компонент — действует как критический привратник и рафинер знаний. Вместо пассивного принятия изначально извлечённых данных, этот агент активно допрашивает их качество, релевантность и полноту, как показано в следующих сценариях.
Во-первых, агент превосходит в рефлексии и валидации источников. Если пользователь спрашивает: "Какова политика нашей компании по удалённой работе?", стандартный RAG может извлечь блог-пост 2020 года наряду с официальным документом политики 2025 года. Агент, однако, проанализировал бы метаданные документов, распознал бы политику 2025 года как наиболее актуальную и авторитетную, и отбросил бы устаревший блог-пост перед отправкой правильного контекста LLM для точного ответа.
Рис.2: Agentic RAG вводит рассуждающего агента, который активно оценивает, согласовывает и уточняет извлечённую информацию для обеспечения более точного и надёжного финального ответа.
Во-вторых, агент адепт в согласовании конфликтов знаний. Представьте, что финансовый аналитик спрашивает: "Каков был бюджет Q1 проекта Альфа?" Система извлекает два документа: первоначальное предложение, указывающее бюджет в €50,000, и финализированный финансовый отчёт, указывающий его как €65,000. Agentic RAG идентифицировал бы это противоречие, приоритизировал финансовый отчёт как более надёжный источник, и предоставил LLM проверенную цифру, обеспечивая, что финальный ответ основан на наиболее точных данных.
В-третьих, агент может выполнять многошаговое рассуждение для синтеза сложных ответов. Если пользователь спрашивает: "Как функции и ценообразование нашего продукта сравниваются с Конкурентом X?", агент разложил бы это на отдельные под-запросы. Он инициировал бы отдельные поиски для функций собственного продукта, его ценообразования, функций Конкурента X и ценообразования Конкурента X. После сбора этих индивидуальных кусков информации агент синтезировал бы их в структурированный, сравнительный контекст перед подачей его LLM, обеспечивая всеобъемлющий ответ, который простое извлечение не могло бы произвести.
В-четвёртых, агент может идентифицировать пробелы в знаниях и использовать внешние инструменты. Предположим, пользователь спрашивает: "Какова была немедленная реакция рынка на наш новый продукт, запущенный вчера?" Агент ищет во внутренней базе знаний, которая обновляется еженедельно, и не находит релевантной информации. Распознавая этот пробел, он может затем активировать инструмент — такой как API живого веб-поиска — для поиска свежих новостных статей и настроений в социальных сетях. Агент затем использует эту свежесобранную внешнюю информацию для предоставления актуального ответа, преодолевая ограничения своей статической внутренней базы данных.
Проблемы Agentic RAG: Хотя мощный, агентный слой вводит свой собственный набор проблем. Основным недостатком является значительное увеличение сложности и стоимости. Проектирование, реализация и поддержание логики принятия решений агента и интеграций инструментов требует существенных инженерных усилий и добавляет к вычислительным расходам. Эта сложность также может привести к увеличенной задержке, поскольку циклы рефлексии, использования инструментов и многошагового рассуждения агента занимают больше времени, чем стандартный, прямой процесс извлечения. Более того, сам агент может стать новым источником ошибок; порочный процесс рассуждения мог бы заставить его застрять в бесполезных циклах, неправильно интерпретировать задачу или неподобающе отбросить релевантную информацию, в конечном счёте ухудшая качество финального ответа.
Резюме:
Agentic RAG представляет сложную эволюцию стандартного паттерна извлечения, трансформируя его из пассивного конвейера данных в активный, решающий проблемы фреймворк. Встраивая слой рассуждения, который может оценивать источники, согласовывать конфликты, разлагать сложные вопросы и использовать внешние инструменты, агенты драматически улучшают надёжность и глубину генерируемых ответов. Это продвижение делает AI более надёжным и способным, хотя оно приходит с важными компромиссами в сложности системы, задержке и стоимости, которые должны быть тщательно управляемы.
Практические применения и случаи использования
Извлечение знаний (RAG) изменяет то, как Large Language Models (LLM) используются в различных отраслях, повышая их способность предоставлять более точные и контекстуально релевантные ответы.
Применения включают:
Корпоративный поиск и вопросы-ответы: Организации могут разрабатывать внутренние чат-боты, которые отвечают на запросы сотрудников, используя внутреннюю документацию, такую как HR-политики, технические руководства и спецификации продуктов. RAG-система извлекает релевантные разделы из этих документов для информирования ответа LLM.
Поддержка клиентов и службы помощи: RAG-основанные системы могут предлагать точные и последовательные ответы на запросы клиентов, обращаясь к информации из руководств по продуктам, часто задаваемых вопросов (FAQ) и тикетов поддержки. Это может снизить потребность в прямом человеческом вмешательстве для рутинных вопросов.
Персонализированные рекомендации контента: Вместо простого сопоставления ключевых слов, RAG может идентифицировать и извлекать контент (статьи, продукты), который семантически связан с предпочтениями пользователя или предыдущими взаимодействиями, приводя к более релевантным рекомендациям.
Суммаризация новостей и текущих событий: LLM могут быть интегрированы с новостными лентами в реальном времени. Когда запрашивается информация о текущем событии, RAG-система извлекает недавние статьи, позволяя LLM производить актуальную сводку.
Включая внешние знания, RAG расширяет возможности LLM за пределы простого общения, позволяя им функционировать как системы обработки знаний.
Практический пример кода (ADK)
Чтобы проиллюстрировать паттерн извлечения знаний (RAG), давайте рассмотрим три примера.
Во-первых, как использовать Google Search для выполнения RAG и обоснования LLM результатами поиска. Поскольку RAG включает доступ к внешней информации, инструмент Google Search является прямым примером встроенного механизма извлечения, который может дополнить знания LLM.
from google.adk.tools import google_search
from google.adk.agents import Agent
search_agent = Agent(
name="research_assistant",
model="gemini-2.0-flash-exp",
instruction="You help users research topics. When asked, use the Google Search tool",
tools=[google_search]
)Во-вторых, этот раздел объясняет, как использовать возможности Vertex AI RAG в рамках Google ADK. Предоставленный код демонстрирует инициализацию VertexAiRagMemoryService из ADK. Это позволяет установить соединение с Google Cloud Vertex AI RAG Corpus. Сервис настраивается путем указания имени ресурса корпуса и дополнительных параметров, таких как SIMILARITY_TOP_K и VECTOR_DISTANCE_THRESHOLD. Эти параметры влияют на процесс извлечения. SIMILARITY_TOP_K определяет количество наиболее похожих результатов для извлечения. VECTOR_DISTANCE_THRESHOLD устанавливает ограничение на семантическое расстояние для извлеченных результатов. Эта настройка позволяет агентам выполнять масштабируемое и постоянное семантическое извлечение знаний из указанного RAG Corpus. Процесс эффективно интегрирует функциональности RAG Google Cloud в агента ADK, тем самым поддерживая разработку ответов, основанных на фактических данных.
# Импортируем необходимый класс VertexAiRagMemoryService из модуля google.adk.memory.
from google.adk.memory import VertexAiRagMemoryService
RAG_CORPUS_RESOURCE_NAME = "projects/your-gcp-project-id/locations/us-central1/ragCorpora/your-corpus-id"
# Определяем дополнительный параметр для количества наиболее похожих результатов для извлечения.
# Это контролирует, сколько релевантных кусков документов вернет RAG-сервис.
SIMILARITY_TOP_K = 5
# Определяем дополнительный параметр для порога векторного расстояния.
# Этот порог определяет максимальное семантическое расстояние, разрешенное для извлеченных результатов;
# результаты с расстоянием больше этого значения могут быть отфильтрованы.
VECTOR_DISTANCE_THRESHOLD = 0.7
# Инициализируем экземпляр VertexAiRagMemoryService.
# Это устанавливает соединение с вашим Vertex AI RAG Corpus.
# - rag_corpus: Указывает уникальный идентификатор для вашего RAG Corpus.
# - similarity_top_k: Устанавливает максимальное количество похожих результатов для извлечения.
# - vector_distance_threshold: Определяет порог сходства для фильтрации результатов.
memory_service = VertexAiRagMemoryService(
rag_corpus=RAG_CORPUS_RESOURCE_NAME,
similarity_top_k=SIMILARITY_TOP_K,
vector_distance_threshold=VECTOR_DISTANCE_THRESHOLD
)Практический пример кода (LangChain)
В-третьих, давайте пройдемся через полный пример, используя LangChain.
import os
import requests
from typing import List, Dict, Any, TypedDict
from langchain_community.document_loaders import TextLoader
from langchain_core.documents import Document
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_community.embeddings import OpenAIEmbeddings
from langchain_community.vectorstores import Weaviate
from langchain_openai import ChatOpenAI
from langchain.text_splitter import CharacterTextSplitter
from langchain.schema.runnable import RunnablePassthrough
from langgraph.graph import StateGraph, END
import weaviate
from weaviate.embedded import EmbeddedOptions
import dotenv
# Загружаем переменные окружения (например, OPENAI_API_KEY)
dotenv.load_dotenv()
# Устанавливаем ваш OpenAI API ключ (убедитесь, что он загружен из .env или установлен здесь)
# os.environ["OPENAI_API_KEY"] = "YOUR_OPENAI_API_KEY"
# --- 1. Подготовка данных (Предобработка) ---
# Загружаем данные
url = "https://github.com/langchain-ai/langchain/blob/master/docs/docs/how_to/state_of_the_union.txt"
res = requests.get(url)
with open("state_of_the_union.txt", "w") as f:
f.write(res.text)
loader = TextLoader('./state_of_the_union.txt')
documents = loader.load()
# Разбиваем документы на куски
text_splitter = CharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = text_splitter.split_documents(documents)
# Встраиваем и сохраняем куски в Weaviate
client = weaviate.Client(
embedded_options=EmbeddedOptions()
)
vectorstore = Weaviate.from_documents(
client=client,
documents=chunks,
embedding=OpenAIEmbeddings(),
by_text=False
)
# Определяем извлекатель
retriever = vectorstore.as_retriever()
# Инициализируем LLM
llm = ChatOpenAI(model_name="gpt-3.5-turbo", temperature=0)
# --- 2. Определяем состояние для LangGraph ---
class RAGGraphState(TypedDict):
question: str
documents: List[Document]
generation: str
# --- 3. Определяем узлы (функции) ---
def retrieve_documents_node(state: RAGGraphState) -> RAGGraphState:
"""Извлекает документы на основе вопроса пользователя."""
question = state["question"]
documents = retriever.invoke(question)
return {"documents": documents, "question": question, "generation": ""}
def generate_response_node(state: RAGGraphState) -> RAGGraphState:
"""Генерирует ответ, используя LLM на основе извлеченных документов."""
question = state["question"]
documents = state["documents"]
# Шаблон prompt из PDF
template = """You are an assistant for question-answering tasks.
Use the following pieces of retrieved context to answer the question.
If you don't know the answer, just say that you don't know.
Use three sentences maximum and keep the answer concise.
Question: {question}
Context: {context}
Answer:
"""
prompt = ChatPromptTemplate.from_template(template)
# Форматируем контекст из документов
context = "\n\n".join([doc.page_content for doc in documents])
# Создаем RAG-цепочку
rag_chain = prompt | llm | StrOutputParser()
# Вызываем цепочку
generation = rag_chain.invoke({"context": context, "question": question})
return {"question": question, "documents": documents, "generation": generation}
# --- 4. Строим граф LangGraph ---
workflow = StateGraph(RAGGraphState)
# Добавляем узлы
workflow.add_node("retrieve", retrieve_documents_node)
workflow.add_node("generate", generate_response_node)
# Устанавливаем точку входа
workflow.set_entry_point("retrieve")
# Добавляем рёбра (переходы)
workflow.add_edge("retrieve", "generate")
workflow.add_edge("generate", END)
# Компилируем граф
app = workflow.compile()
# --- 5. Запускаем RAG-приложение ---
if __name__ == "__main__":
print("\n--- Запуск RAG-запроса ---")
query = "What did the president say about Justice Breyer"
inputs = {"question": query}
for s in app.stream(inputs):
print(s)
print("\n--- Запуск другого RAG-запроса ---")
query_2 = "What did the president say about the economy?"
inputs_2 = {"question": query_2}
for s in app.stream(inputs_2):
print(s)Этот Python-код иллюстрирует конвейер Retrieval-Augmented Generation (RAG), реализованный с помощью LangChain и LangGraph. Процесс начинается с создания базы знаний, полученной из текстового документа, который сегментируется на куски и преобразуется в embeddings. Эти embeddings затем сохраняются в векторном хранилище Weaviate, облегчая эффективное извлечение информации. StateGraph в LangGraph используется для управления рабочим потоком между двумя ключевыми функциями: retrieve_documents_node и generate_response_node. Функция retrieve_documents_node запрашивает векторное хранилище для идентификации релевантных кусков документов на основе пользовательского ввода. Впоследствии функция generate_response_node использует извлеченную информацию и предопределенный шаблон prompt для создания ответа, используя OpenAI Large Language Model (LLM). Метод app.stream позволяет выполнение запросов через RAG-конвейер, демонстрируя способность системы генерировать контекстуально релевантные выходы.
В двух словах
Что: LLM обладают впечатляющими способностями генерации текста, но принципиально ограничены своими данными обучения. Эти знания статичны, то есть не включают информацию в реальном времени или частные, специфичные для домена данные. Следовательно, их ответы могут быть устаревшими, неточными или лишенными специфического контекста, необходимого для специализированных задач. Этот пробел ограничивает их надежность для приложений, требующих актуальных и фактических ответов.
Почему: Паттерн Retrieval-Augmented Generation (RAG) предоставляет стандартизированное решение, подключая LLM к внешним источникам знаний. Когда получен запрос, система сначала извлекает релевантные фрагменты информации из указанной базы знаний. Эти фрагменты затем добавляются к исходному prompt, обогащая его своевременным и специфическим контекстом. Этот дополненный prompt затем отправляется к LLM, позволяя ему генерировать ответ, который точен, поддается проверке и обоснован внешними данными. Этот процесс эффективно трансформирует LLM из рассуждающего "с закрытой книгой" в рассуждающего "с открытой книгой", значительно повышая его полезность и надежность.
Практическое правило: Используйте этот паттерн, когда вам нужно, чтобы LLM отвечал на вопросы или генерировал контент на основе специфической, актуальной или проприетарной информации, которая не была частью его исходных данных обучения. Он идеален для построения систем вопросов-ответов по внутренним документам, ботов поддержки клиентов и приложений, требующих поддающихся проверке, основанных на фактах ответов с цитатами.
Визуальная сводка
Паттерн извлечения знаний: AI-агент для запроса и извлечения информации из структурированных баз данных
Рис. 3: Паттерн извлечения знаний: AI-агент для поиска и синтеза информации из публичного интернета в ответ на запросы пользователей.
Ключевые выводы
- Извлечение знаний (RAG) расширяет возможности LLM, позволяя им получать доступ к внешней, актуальной и специфической информации.
- Процесс включает извлечение (поиск в базе знаний релевантных фрагментов) и дополнение (добавление этих фрагментов к prompt LLM).
- RAG помогает LLM преодолевать ограничения, такие как устаревшие данные обучения, снижает "галлюцинации" и обеспечивает интеграцию специфических для домена знаний.
- RAG позволяет получать атрибутированные ответы, поскольку ответ LLM обоснован извлеченными источниками.
- GraphRAG использует граф знаний для понимания взаимосвязей между различными фрагментами информации, позволяя отвечать на сложные вопросы, требующие синтеза данных из множественных источников.
- Agentic RAG выходит за рамки простого извлечения информации, используя интеллектуального агента для активного рассуждения, валидации и уточнения внешних знаний, обеспечивая более точный и надежный ответ.
- Практические применения охватывают корпоративный поиск, поддержку клиентов, юридические исследования и персонализированные рекомендации.
Заключение
В заключение, Retrieval-Augmented Generation (RAG) решает основное ограничение статических знаний Large Language Model, подключая их к внешним, актуальным источникам данных. Процесс работает путем первоначального извлечения релевантных фрагментов информации и последующего дополнения prompt пользователя, позволяя LLM генерировать более точные и контекстуально осведомленные ответы. Это становится возможным благодаря основополагающим технологиям, таким как embeddings, семантический поиск и векторные базы данных, которые находят информацию на основе значения, а не только ключевых слов. Обосновывая выходы поддающимися проверке данными, RAG значительно снижает фактические ошибки и позволяет использовать проприетарную информацию, повышая доверие через цитаты.
Продвинутая эволюция, Agentic RAG, вводит слой рассуждения, который активно валидирует, согласовывает и синтезирует извлеченные знания для еще большей надежности. Аналогично, специализированные подходы, такие как GraphRAG, используют графы знаний для навигации по явным взаимосвязям данных, позволяя системе синтезировать ответы на высоко сложные, взаимосвязанные запросы. Этот агент может разрешать конфликтующую информацию, выполнять многошаговые запросы и использовать внешние инструменты для поиска недостающих данных. Хотя эти продвинутые методы добавляют сложность и задержку, они драматически улучшают глубину и надежность финального ответа. Практические применения этих паттернов уже трансформируют отрасли, от корпоративного поиска и поддержки клиентов до персонализированной доставки контента. Несмотря на проблемы, RAG является критическим паттерном для повышения знаний, надежности и полезности AI. В конечном счете, он трансформирует LLM из собеседников с закрытой книгой в мощные инструменты рассуждения с открытой книгой.
Литература
- Lewis, P., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. https://arxiv.org/abs/2005.11401
- Google AI for Developers Documentation. Retrieval Augmented Generation - https://cloud.google.com/vertex-ai/generative-ai/docs/rag-engine/rag-overview
- Retrieval-Augmented Generation with Graphs (GraphRAG)
- LangChain and LangGraph: Leonie Monigatti, "Retrieval-Augmented Generation (RAG): From Theory to LangChain Implementation," https://medium.com/data-science/retrieval-augmented-generation-rag-from-theory-to-langchain-implementation-4e9bd5f6a4f2
- Google Cloud Vertex AI RAG Corpus https://cloud.google.com/vertex-ai/generative-ai/docs/rag-engine/manage-your-rag-corpus#corpus-management
Навигация
Назад: Глава 13. Человек в контуре
Вперед: Глава 15. Межагентная коммуникация